home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group03a.txt / 000022_icon-group-sender_Fri Feb 28 12:28:03 2003.msg < prev    next >
Internet Message Format  |  2003-12-22  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id h1SJQ6Q22581
  4.     for icon-group-addresses; Fri, 28 Feb 2003 12:26:06 -0700 (MST)
  5. Message-Id: <200302281926.h1SJQ6Q22581@baskerville.CS.Arizona.EDU>
  6. From: "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: GUI Front End for icont
  9. X-Priority: 3
  10. X-MSMail-Priority: Normal
  11. X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
  12. X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
  13. Date: Fri, 28 Feb 2003 18:37:31 GMT
  14. X-Complaints-To: abuse@verizon.net
  15. To: icon-group@cs.arizona.edu
  16. Errors-To: icon-group-errors@cs.arizona.edu
  17. Status: RO
  18.  
  19. In some previous versions of Icon for MS Windows, there were two separate
  20. sets of Icon tools: one for command line interface  (CLI) applications, and
  21. one for Graphic User Interface (GUI) applications:
  22.  
  23. - For CLI applications, the Icon compiler was called "nticont.exe", and it
  24. used "nticonx.exe"as the interpreter; and
  25. - For GUI applications, the Icon compiler was called "wicont.exe", and it
  26. used "wiconx.exe" as the interpreter.
  27.  
  28. Needless to say, the need for the source files to support both sets of tools
  29. requires lots of MS Win-specific code, creating a maintenance nightmare. As
  30. a result, the Windows port of Icon has lagged behind ports on other
  31. platforms.
  32.  
  33. I considered this approach unnecessarily complex, so a while back I worked
  34. on having one set of tools that could be used to build and run both CLI and
  35. GUI applications. To accomplish this, I ported the Unix Icon code to the
  36. Cygwin compiler, keeping the MS Windows code for the graphics facility. The
  37. result of this effort is a icont / iconx pair that can be used to compile
  38. and execute Icon applications that use CLI, GUI, or both.
  39.  
  40. On the one hand, this port was extremely successful. The Cygwin version of
  41. Icon is much closer to Icon on other platforms, and the number of source
  42. code differences between Unix Icon and MS Icon has been significantly
  43. diminished. On the other hand, there is something that has been lost in this
  44. process. The MS Windows version of the Icon compiler for developing GUI
  45. application used to be a GUI application itself. This is not the case with
  46. the Cygwin version of icont.
  47.  
  48. Of course, one way we could get back a GUI for compiling and linking Icon
  49. programs is to develop a GUI front end for the CLI version of icont. In a
  50. sense, that is what Microsoft does with its compilers. For all the fancy
  51. features of Visual C++, when the GUI actually compiles a C/C++ file, it
  52. simply runs the CLI tool CL.EXE with the appropriate arguments. Presumably,
  53. this could also be done with icont.
  54.  
  55. One could develop the GUI front end using C / C++ and the Win32 API, but if
  56. we do this, the GUI would only live on the MS Windows platform. A more
  57. portable approach is possible: why not develop the GUI front end in Icon? By
  58. doing so, the GUI front end can be ported to any platform where Icon
  59. supports graphics.
  60.  
  61. So, is the Icon graphics facility up to the challenge of the GUI front end?
  62.  
  63.  
  64.